home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000100_owner-urn-ietf _Thu Oct 24 15:33:30 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  2KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18019 for urn-ietf-out; Thu, 24 Oct 1996 15:33:30 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18014 for <urn-ietf@services.bunyip.com>; Thu, 24 Oct 1996 15:33:27 -0400
  3. Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA29015  (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:33:26 -0400
  5. Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id MAA17796; Thu, 24 Oct 1996 12:31:49 -0700
  6. Date: Thu, 24 Oct 1996 12:31:49 -0700 (PDT)
  7. From: "Gregory J. Woodhouse" <gjw@wnetc.com>
  8. To: Martin J Duerst <mduerst@ifi.unizh.ch>
  9. Cc: tallen@fsc.fujitsu.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  10. Subject: Re: [URN] Unicode for NSS query
  11. In-Reply-To: <"josef.ifi..192:24.09.96.20.15.32"@ifi.unizh.ch>
  12. Message-Id: <Pine.SGI.3.95.961024122748.18743D-100000@shellx.best.com>
  13. X-Url: http://www.wnetc.com/
  14. Mime-Version: 1.0
  15. Content-Type: TEXT/PLAIN; charset=US-ASCII
  16. Sender: owner-urn-ietf@services.bunyip.com
  17. Precedence: bulk
  18. Reply-To: "Gregory J. Woodhouse" <gjw@wnetc.com>
  19. Errors-To: owner-urn-ietf@bunyip.com
  20.  
  21. On Thu, 24 Oct 1996, Martin J Duerst wrote:
  22.  
  23. > 
  24. > I have suggested that we might be required to thing in terms of
  25. > both characters and octets. For some things, similar to a data:
  26. > URL, thinking in characters might be artificial. For some
  27. > other things, such as URLs, thinking in octets may to some
  28. > extent be necessary because of backwards compatibility issues
  29. > (assume an URL scheme is extended and decides to use some
  30. > weird RFC 1522-like method for encoding characters, and this
  31. > would have to be grandfathered).
  32. >
  33.  
  34. I have thought about the same thing, and I admit that I am not altogether
  35. enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
  36. upon us. 
  37.  
  38.  
  39. ---
  40. Gregory Woodhouse     gjw@wnetc.com
  41. home page:            http://www.wnetc.com/
  42. resource page:        http://www.wnetc.com/resource/
  43.